.limit(1000) hard-caps the candidate set, so pagination and total become incorrect whenever a deployment has >1000 versions (and offset > 999 will always return an empty page). If this limit is meant as a safety cap, it should be enforced via API validation and reflected in the response/error; otherwise, fetch all versions for accurate totals or implement chunked fetching until offset + limit items are collected and the full filtered total is known.

When cel is not provided, the handler still loads up to 1000 rows and paginates in memory. This ignores the requested limit/offset at the database level and can add unnecessary DB/network load compared to applying .limit(limit).offset(offset) in the query for the non-CEL case.

⚠️ Potential issue | 🟡 Minor

Silent catch { return false } makes invalid CEL expressions indistinguishable from empty results.

validResourceSelector only validates parse-time syntax (via cel-js parse), not runtime evaluation. A syntactically valid expression that references an unknown field, mis-types a comparison, or otherwise throws at evaluate-time will cause every candidate to be dropped and the endpoint will return { items: [], total: 0 } with HTTP 200 — users will have no way to tell their expression is wrong.

Two options, either is fine:

1. Log the evaluation error at least once per request so operators can diagnose, e.g.:

 function filterDeploymentVersions(
   versions: (typeof schema.deploymentVersion.$inferSelect)[],
   cel: string,
 ) {
+  let loggedError = false;
   return versions.filter((version) => {
     try {
       return evaluate(cel, { deploymentVersion: version });
-    } catch {
+    } catch (err) {
+      if (!loggedError) {
+        console.warn("CEL evaluation failed for deployment version", {
+          cel,
+          versionId: version.id,
+          error: err,
+        });
+        loggedError = true;
+      }
       return false;
     }
   });
 }

2. Evaluate once up-front against a representative candidate and reject the whole request with a 400 if it throws, so the caller gets actionable feedback instead of an empty list.

Verify each finding against the current code and only fix it if needed.

In `@apps/api/src/routes/v1/workspaces/deployments.ts` around lines 262 - 273, The
current filterDeploymentVersions function swallows runtime CEL evaluation errors
(catch { return false }) making bad selectors return empty results; change this
by performing an up-front evaluation of the CEL expression (using evaluate)
against a representative candidate (e.g., the first element of versions) in the
request handling code (or inside filterDeploymentVersions) and if evaluate
throws, surface a 400 Bad Request (or throw an error that your route handler
converts to 400) with the evaluation error message; then update
filterDeploymentVersions to not silently swallow errors (remove the empty catch
so evaluation errors propagate) so valid evaluations filter normally while
invalid selectors return a clear error instead of an empty list.

⚠️ Potential issue | 🟠 Major

Hard 1000-candidate cap silently truncates total and pagination.

When cel is supplied, candidates are capped at 1000 before filtering and total is reported as filtered.length. For any deployment with >1000 versions this is misleading in two ways:

• total no longer reflects the real number of matches — it's bounded by how many of the top-1000 (by createdAt) happen to match. A client seeing total: 37 cannot tell whether there are genuinely 37 matches or 37 within the first 1000 of many thousands.
• Clients paginating with offset/limit can never reach matches that live outside the 1000-candidate window, so the endpoint will silently omit results.

At minimum, surface the cap to the caller (e.g., an additional flag like truncated: true when candidates.length === 1000, or expose the candidate-window size separately from the match count) and document the behavior on the OpenAPI spec. Longer-term, consider pushing CEL → SQL translation for common predicates, or iterating in DB-ordered chunks until offset + limit post-filter results are found.

Verify each finding against the current code and only fix it if needed.

In `@apps/api/src/routes/v1/workspaces/deployments.ts` around lines 317 - 333, The
current flow fetches up to 1000 candidates into candidates (query on
schema.deploymentVersion), runs filterDeploymentVersions(candidates, cel) and
returns total: filtered.length which can mislead callers; change the response to
include a truncated indicator and the candidate window size so callers know
results were capped. Specifically, after fetching candidates, set a boolean
truncated = candidates.length === 1000 and include truncated (and optionally
candidateWindow: candidates.length) in the JSON response alongside items, total,
limit, offset; keep using filtered.length for total but surface the cap so
clients can detect truncation. Ensure you update the handler that constructs the
response (the block that calls filterDeploymentVersions and
res.status(200).json(...)) to add these fields and keep existing fields
unchanged.

Will this be sufficient? What if you looped pages of 1000 until you got enough results?